<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="generator" content="AsciiDoc 8.6.3" />
<title>Gerrit Code Review - Contributing</title>
<style type="text/css">
/* Sans-serif font. */
h1, h2, h3, h4, h5, h6,
div.title, caption.title,
thead, p.table.header,
div#toctitle,
span#author, span#revnumber, span#revdate, span#revremark,
div#footer {
  font-family: Arial,Helvetica,sans-serif;
}

/* Serif font. */
div.sectionbody {
  font-family: Georgia,"Times New Roman",Times,serif;
}

/* Monospace font. */
tt {
  font-size: inherit;
}

body {
  margin: 1em 5% 1em 5%;
}

a {
  color: blue;
  text-decoration: underline;
}
a:visited {
  color: fuchsia;
}

em {
  font-style: italic;
  color: navy;
}

strong {
  font-weight: bold;
  color: #083194;
}

tt {
  font-size: inherit;
  color: navy;
}

h1, h2, h3, h4, h5, h6 {
  color: #527bbd;
  margin-top: 1.2em;
  margin-bottom: 0.5em;
  line-height: 1.3;
}

h1, h2, h3 {
  border-bottom: 2px solid silver;
}
h2 {
  padding-top: 0.5em;
}
h3 {
  float: left;
}
h3 + * {
  clear: left;
}

div.sectionbody {
  margin-left: 0;
}

hr {
  border: 1px solid silver;
}

p {
  margin-top: 0.5em;
  margin-bottom: 0.5em;
}

ul, ol, li > p {
  margin-top: 0;
}
ul > li     { color: #aaa; }
ul > li > * { color: black; }

pre {
  padding: 0;
  margin: 0;
}

span#author {
  color: #527bbd;
  font-weight: bold;
  font-size: 1.1em;
}
span#email {
}
span#revnumber, span#revdate, span#revremark {
}

div#footer {
  font-size: small;
  border-top: 2px solid silver;
  padding-top: 0.5em;
  margin-top: 4.0em;
}
div#footer-text {
  float: left;
  padding-bottom: 0.5em;
}
div#footer-badges {
  float: right;
  padding-bottom: 0.5em;
}

div#preamble {
  margin-top: 1.5em;
  margin-bottom: 1.5em;
}
div.tableblock, div.imageblock, div.exampleblock, div.verseblock,
div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
div.admonitionblock {
  margin-top: 1.0em;
  margin-bottom: 1.5em;
}
div.admonitionblock {
  margin-top: 2.0em;
  margin-bottom: 2.0em;
  margin-right: 10%;
  color: #606060;
}

div.content { /* Block element content. */
  padding: 0;
}

/* Block element titles. */
div.title, caption.title {
  color: #527bbd;
  font-weight: bold;
  text-align: left;
  margin-top: 1.0em;
  margin-bottom: 0.5em;
}
div.title + * {
  margin-top: 0;
}

td div.title:first-child {
  margin-top: 0.0em;
}
div.content div.title:first-child {
  margin-top: 0.0em;
}
div.content + div.title {
  margin-top: 0.0em;
}

div.sidebarblock > div.content {
  background: #ffffee;
  border: 1px solid #dddddd;
  border-left: 4px solid #f0f0f0;
  padding: 0.5em;
}

div.listingblock > div.content {
  border: 1px solid #dddddd;
  border-left: 5px solid #f0f0f0;
  background: #f8f8f8;
  padding: 0.5em;
}

div.quoteblock, div.verseblock {
  padding-left: 1.0em;
  margin-left: 1.0em;
  margin-right: 10%;
  border-left: 5px solid #f0f0f0;
  color: #777777;
}

div.quoteblock > div.attribution {
  padding-top: 0.5em;
  text-align: right;
}

div.verseblock > pre.content {
  font-family: inherit;
  font-size: inherit;
}
div.verseblock > div.attribution {
  padding-top: 0.75em;
  text-align: left;
}
/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
div.verseblock + div.attribution {
  text-align: left;
}

div.admonitionblock .icon {
  vertical-align: top;
  font-size: 1.1em;
  font-weight: bold;
  text-decoration: underline;
  color: #527bbd;
  padding-right: 0.5em;
}
div.admonitionblock td.content {
  padding-left: 0.5em;
  border-left: 3px solid #dddddd;
}

div.exampleblock > div.content {
  border-left: 3px solid #dddddd;
  padding-left: 0.5em;
}

div.imageblock div.content { padding-left: 0; }
span.image img { border-style: none; }
a.image:visited { color: white; }

dl {
  margin-top: 0.8em;
  margin-bottom: 0.8em;
}
dt {
  margin-top: 0.5em;
  margin-bottom: 0;
  font-style: normal;
  color: navy;
}
dd > *:first-child {
  margin-top: 0.1em;
}

ul, ol {
    list-style-position: outside;
}
ol.arabic {
  list-style-type: decimal;
}
ol.loweralpha {
  list-style-type: lower-alpha;
}
ol.upperalpha {
  list-style-type: upper-alpha;
}
ol.lowerroman {
  list-style-type: lower-roman;
}
ol.upperroman {
  list-style-type: upper-roman;
}

div.compact ul, div.compact ol,
div.compact p, div.compact p,
div.compact div, div.compact div {
  margin-top: 0.1em;
  margin-bottom: 0.1em;
}

div.tableblock > table {
  border: 3px solid #527bbd;
}
thead, p.table.header {
  font-weight: bold;
  color: #527bbd;
}
tfoot {
  font-weight: bold;
}
td > div.verse {
  white-space: pre;
}
p.table {
  margin-top: 0;
}
/* Because the table frame attribute is overriden by CSS in most browsers. */
div.tableblock > table[frame="void"] {
  border-style: none;
}
div.tableblock > table[frame="hsides"] {
  border-left-style: none;
  border-right-style: none;
}
div.tableblock > table[frame="vsides"] {
  border-top-style: none;
  border-bottom-style: none;
}


div.hdlist {
  margin-top: 0.8em;
  margin-bottom: 0.8em;
}
div.hdlist tr {
  padding-bottom: 15px;
}
dt.hdlist1.strong, td.hdlist1.strong {
  font-weight: bold;
}
td.hdlist1 {
  vertical-align: top;
  font-style: normal;
  padding-right: 0.8em;
  color: navy;
}
td.hdlist2 {
  vertical-align: top;
}
div.hdlist.compact tr {
  margin: 0;
  padding-bottom: 0;
}

.comment {
  background: yellow;
}

.footnote, .footnoteref {
  font-size: 0.8em;
}

span.footnote, span.footnoteref {
  vertical-align: super;
}

#footnotes {
  margin: 20px 0 20px 0;
  padding: 7px 0 0 0;
}

#footnotes div.footnote {
  margin: 0 0 5px 0;
}

#footnotes hr {
  border: none;
  border-top: 1px solid silver;
  height: 1px;
  text-align: left;
  margin-left: 0;
  width: 20%;
  min-width: 100px;
}

div.colist td {
  padding-right: 0.5em;
  padding-bottom: 0.3em;
  vertical-align: top;
}
div.colist td img {
  margin-top: 0.3em;
}

@media print {
  div#footer-badges { display: none; }
}

div#toc {
  margin-bottom: 2.5em;
}

div#toctitle {
  color: #527bbd;
  font-size: 1.1em;
  font-weight: bold;
  margin-top: 1.0em;
  margin-bottom: 0.1em;
}

div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
  margin-top: 0;
  margin-bottom: 0;
}
div.toclevel2 {
  margin-left: 2em;
  font-size: 0.9em;
}
div.toclevel3 {
  margin-left: 4em;
  font-size: 0.9em;
}
div.toclevel4 {
  margin-left: 6em;
  font-size: 0.9em;
}

</style>
<script type="text/javascript">
/*<![CDATA[*/
window.onload = function(){asciidoc.footnotes(); asciidoc.toc(2);}
var asciidoc = {  // Namespace.

/////////////////////////////////////////////////////////////////////
// Table Of Contents generator
/////////////////////////////////////////////////////////////////////

/* Author: Mihai Bazon, September 2002
 * http://students.infoiasi.ro/~mishoo
 *
 * Table Of Content generator
 * Version: 0.4
 *
 * Feel free to use this script under the terms of the GNU General Public
 * License, as long as you do not remove or alter this notice.
 */

 /* modified by Troy D. Hanson, September 2006. License: GPL */
 /* modified by Stuart Rackham, 2006, 2009. License: GPL */

// toclevels = 1..4.
toc: function (toclevels) {

  function getText(el) {
    var text = "";
    for (var i = el.firstChild; i != null; i = i.nextSibling) {
      if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
        text += i.data;
      else if (i.firstChild != null)
        text += getText(i);
    }
    return text;
  }

  function TocEntry(el, text, toclevel) {
    this.element = el;
    this.text = text;
    this.toclevel = toclevel;
  }

  function tocEntries(el, toclevels) {
    var result = new Array;
    var re = new RegExp('[hH]([2-'+(toclevels+1)+'])');
    // Function that scans the DOM tree for header elements (the DOM2
    // nodeIterator API would be a better technique but not supported by all
    // browsers).
    var iterate = function (el) {
      for (var i = el.firstChild; i != null; i = i.nextSibling) {
        if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
          var mo = re.exec(i.tagName);
          if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
            result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
          }
          iterate(i);
        }
      }
    }
    iterate(el);
    return result;
  }

  var toc = document.getElementById("toc");
  var entries = tocEntries(document.getElementById("content"), toclevels);
  for (var i = 0; i < entries.length; ++i) {
    var entry = entries[i];
    if (entry.element.id == "")
      entry.element.id = "_toc_" + i;
    var a = document.createElement("a");
    a.href = "#" + entry.element.id;
    a.appendChild(document.createTextNode(entry.text));
    var div = document.createElement("div");
    div.appendChild(a);
    div.className = "toclevel" + entry.toclevel;
    toc.appendChild(div);
  }
  if (entries.length == 0)
    toc.parentNode.removeChild(toc);
},


/////////////////////////////////////////////////////////////////////
// Footnotes generator
/////////////////////////////////////////////////////////////////////

/* Based on footnote generation code from:
 * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
 */

footnotes: function () {
  var cont = document.getElementById("content");
  var noteholder = document.getElementById("footnotes");
  var spans = cont.getElementsByTagName("span");
  var refs = {};
  var n = 0;
  for (i=0; i<spans.length; i++) {
    if (spans[i].className == "footnote") {
      n++;
      // Use [\s\S] in place of . so multi-line matches work.
      // Because JavaScript has no s (dotall) regex flag.
      note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
      noteholder.innerHTML +=
        "<div class='footnote' id='_footnote_" + n + "'>" +
        "<a href='#_footnoteref_" + n + "' title='Return to text'>" +
        n + "</a>. " + note + "</div>";
      spans[i].innerHTML =
        "[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
        "' title='View footnote' class='footnote'>" + n + "</a>]";
      var id =spans[i].getAttribute("id");
      if (id != null) refs["#"+id] = n;
    }
  }
  if (n == 0)
    noteholder.parentNode.removeChild(noteholder);
  else {
    // Process footnoterefs.
    for (i=0; i<spans.length; i++) {
      if (spans[i].className == "footnoteref") {
        var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
        href = href.match(/#.*/)[0];  // Because IE return full URL.
        n = refs[href];
        spans[i].innerHTML =
          "[<a href='#_footnote_" + n +
          "' title='View footnote' class='footnote'>" + n + "</a>]";
      }
    }
  }
}

}
/*]]>*/
</script>
</head>
<body class="article">
<div id="header">
<h1>Gerrit Code Review - Contributing</h1>
<span id="revnumber">version 2.5</span>
<div id="toc">
  <div id="toctitle">Table of Contents</div>
  <noscript><p><b>JavaScript must be enabled in your browser to display the table of contents.</b></p></noscript>
</div>
</div>
<div id="content">
<div id="preamble">
<div class="sectionbody">
<div class="paragraph"><p>Gerrit is developed as a self-hosting open source project and
very much welcomes contributions from anyone with a contributor&#8217;s
agreement on file with the project.</p></div>
<div class="ulist"><ul>
<li>
<p>
<a href="https://gerrit-review.googlesource.com/">https://gerrit-review.googlesource.com/</a>
</p>
</li>
</ul></div>
<div class="paragraph"><p>The Contributor License Agreements:</p></div>
<div class="ulist"><ul>
<li>
<p>
<a href="https://gerrit-review.googlesource.com/static/cla_individual.html">https://gerrit-review.googlesource.com/static/cla_individual.html</a>
</p>
</li>
<li>
<p>
<a href="https://gerrit-review.googlesource.com/static/cla_corporate.html">https://gerrit-review.googlesource.com/static/cla_corporate.html</a>
</p>
</li>
</ul></div>
<div class="paragraph"><p>As Gerrit is a code review tool, naturally contributions will
be reviewed before they will get submitted to the code base.  To
start your contribution, please make a git commit and upload it
for review to the main Gerrit review server.  To help speed up the
review of your change, review these guidelines before submitting
your change.  You can view the pending Gerrit contributions and
their statuses here:</p></div>
<div class="ulist"><ul>
<li>
<p>
<a href="https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit,n,z">https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit,n,z</a>
</p>
</li>
</ul></div>
<div class="paragraph"><p>Depending on the size of that list it might take a while for
your change to get reviewed.  Naturally there are fewer
approvers than contributors; so anything that you can do to
ensure that your contribution will undergo fewer revisions
will speed up the contribution process.  This includes helping
out reviewing other people&#8217;s changes to relieve the load from
the approvers.  Even if you are not familiar with Gerrit&#8217;s
internals, it would be of great help if you can download, try
out, and comment on new features.  If it works as advertised,
say so, and if you have the priviliges to do so, go ahead
and give it a +1 Verified.  If you would find the feature
useful, say so and give it a +1 code review.</p></div>
<div class="paragraph"><p>And finally, the quicker you respond to the comments of your
reviewers, the quicker your change might get merged!  Try to
reply to every comment after submitting your new patch,
particularly if you decided against making the suggested change.
Reviewers don&#8217;t want to seem like nags and pester you if you
haven&#8217;t replied or made a fix, so it helps them know if you
missed it or decided against it.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_review_criteria">Review Criteria</h2>
<div class="sectionbody">
<div class="paragraph"><p>Here are some hints as to what approvers may be looking for
before approving or submitting changes to the Gerrit project.
Let&#8217;s start with the simple nit picky stuff.  You are likely
excited that your code works; help us share your excitement
by not distracting us with the simple stuff.  Thanks to Gerrit,
problems are often highlighted and we find it hard to look
beyond simple spacing issues.  Blame it on our short attention
spans, we really do want your code.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_commit_message">Commit Message</h2>
<div class="sectionbody">
<div class="paragraph"><p>It is essential to have a good commit message if you want your
change to be reviewed.</p></div>
<div class="ulist"><ul>
<li>
<p>
Keep lines no longer than 72 chars
</p>
</li>
<li>
<p>
Start with a short one line summary
</p>
</li>
<li>
<p>
Followed by a blank line
</p>
</li>
<li>
<p>
Followed by one or more explanatory paragraphs
</p>
</li>
<li>
<p>
Use the present tense (fix instead of fixed)
</p>
</li>
<li>
<p>
Include a Bug: Issue &lt;#&gt; line if fixing a Gerrit issue
</p>
</li>
<li>
<p>
Include a Change-Id line
</p>
</li>
</ul></div>
<div class="sect2">
<h3 id="_a_sample_good_gerrit_commit_message">A sample good Gerrit commit message:</h3>
<div class="exampleblock">
<div class="content">
<div class="literalblock">
<div class="content">
<pre><tt>Add sample commit message to guidelines doc</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><tt>The original patch set for the contributing guidelines doc did not
include a sample commit message, this new patchset does.  Hopefully this
makes things a bit clearer since examples can sometimes help when
explanations don't.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><tt>Note that the body of this commit message can be several paragraphs, and
that I word wrap it at 72 characters.  Also note that I keep the summary
line under 50 characters since it is often truncated by tools which
display just the git summary.</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><tt>Bug: Issue 98765605
Change-Id: Ic4a7c07eeb98cdeaf44e9d231a65a51f3fceae52</tt></pre>
</div></div>
</div></div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_style">Style</h2>
<div class="sectionbody">
<div class="paragraph"><p>The basic coding style is covered by the tools/GoogleFormat.xml
doc, see the <a href="dev-eclipse.html#Formatting">Eclipse Setup</a>
for that.</p></div>
<div class="paragraph"><p>Highlighted/additional styling notes:</p></div>
<div class="ulist"><ul>
<li>
<p>
It is generally more important to match the style of the nearby
    code which you are modifying than it is to match the style
    in the formatting guidelines.  This is especially true within the
    same file.
</p>
</li>
<li>
<p>
Review your change in Gerrit to see if it highlights
    mistakingly deleted/added spaces on lines, trailing spaces.
</p>
</li>
<li>
<p>
Line length should be 80 or less, unless the code reads
    better with something slightly longer.  Shorter lines not only
    help reviewers who may use a tablet to review the code, but future
    contributors may also like to open several editors side by
    side while editing new changes.
</p>
</li>
<li>
<p>
Use 2 spaces for indent (no tabs)
</p>
</li>
<li>
<p>
Use brackets in all ifs, spaces before/after if parens.
</p>
</li>
<li>
<p>
Use /** */ style Javadocs for variables.
</p>
</li>
</ul></div>
<div class="paragraph"><p>Additionally, you will notice that most of the newline spacing
is fairly consistent throughout the code in Gerrit, it helps to
stick to the blank line conventions.  Here are some specific
examples:</p></div>
<div class="ulist"><ul>
<li>
<p>
Keep a blank line between all class and method declarations.
</p>
</li>
<li>
<p>
Do not add blank lines at the beginning or end of class/methods.
</p>
</li>
<li>
<p>
Put a blank line between external import sources, but not
    between internal ones.
</p>
</li>
</ul></div>
</div>
</div>
<div class="sect1">
<h2 id="_code_organization">Code Organization</h2>
<div class="sectionbody">
<div class="paragraph"><p>Do your best to organize classes and methods in a logical way.
Here are some guidelines that Gerrit uses:</p></div>
<div class="ulist"><ul>
<li>
<p>
Ensure a standard copyright header is included at the top
    of any new files (copy it from another file, update the year).
</p>
</li>
<li>
<p>
Always place loggers first in your class!
</p>
</li>
<li>
<p>
Define any static interfaces next in your class.
</p>
</li>
<li>
<p>
Define non static interfaces after static interfaces in your
    class.
</p>
</li>
<li>
<p>
Next you should define static types and members.
</p>
</li>
<li>
<p>
Finally instance members, then constuctors, and then instance
    methods.
</p>
</li>
<li>
<p>
Some common exceptions are private helper static methods which
    might appear near the instance methods which they help.
</p>
</li>
<li>
<p>
Getters and setters for the same instance field should usually
    be near each other baring a good reason not to.
</p>
</li>
<li>
<p>
If you are using assisted injection, the factory for your class
    should be before the instance members.
</p>
</li>
<li>
<p>
Annotations should go before language keywords (final, private&#8230;)<br />
    Example: @Assisted @Nullable final type varName
</p>
</li>
<li>
<p>
Imports should be mostly alphabetical (uppercase sorts before
    all lowercase, which means classes come before packages at the
    same level).
</p>
</li>
</ul></div>
<div class="paragraph"><p>Wow that&#8217;s a lot!  But don&#8217;t worry, you&#8217;ll get the habit and most
of the code is organized this way already; so if you pay attention
to the class you are editing you will likely pick up on it.
Naturally new classes are a little harder; you may want to come
back and consult this section when creating them.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_design">Design</h2>
<div class="sectionbody">
<div class="paragraph"><p>Here are some design level objectives that you should keep in mind
when coding:</p></div>
<div class="ulist"><ul>
<li>
<p>
ORM entity objects should match exactly one row in the database.
</p>
</li>
<li>
<p>
Most client pages should perform only one RPC to load so as to
    keep latencies down.  Exceptions would apply to RPCs which need
    to load large data sets if splitting them out will help the
    page load faster.  Generally page loads are expected to complete
    in under 100ms.  This will be the case for most operations,
    unless the data being fetched is not using Gerrit&#8217;s caching
    infrastructure.  In these slower cases, it is worth considering
    mitigating this longer load by using a second RPC to fill in
    this data after the page is displayed (or alternatively it might
    be worth proposing caching this data).
</p>
</li>
<li>
<p>
@Inject should be used on constructors, not on fields.  The
    current exceptions are the ssh commands, these were implemented
    earlier in Gerrit&#8217;s development.  To stay consistent, new ssh
    commands should follow this older pattern; but eventually these
    should get converted to eliminate this exception.
</p>
</li>
<li>
<p>
Don&#8217;t leave repository objects (git or schema) open.  A .close()
    after every open should be placed in a finally{} block.
</p>
</li>
<li>
<p>
Don&#8217;t leave UI components, which can cause new actions to occur,
    enabled during RPCs which update the DB.  This is to prevent
    people from submitting actions more than once when operating
    on slow links.  If the action buttons are disabled, they cannot
    be resubmitted and the user can see that Gerrit is still busy.
</p>
</li>
<li>
<p>
GWT EventBus is the new way forward.
</p>
</li>
<li>
<p>
&#8230;and so is Guava (previously known as Google Collections).
</p>
</li>
</ul></div>
</div>
</div>
<div class="sect1">
<h2 id="_tests">Tests</h2>
<div class="sectionbody">
<div class="ulist"><ul>
<li>
<p>
Tests for new code will greatly help your change get approved.
</p>
</li>
</ul></div>
</div>
</div>
<div class="sect1">
<h2 id="_change_size_number_of_files_touched">Change Size/Number of Files Touched</h2>
<div class="sectionbody">
<div class="paragraph"><p>And finally, I probably cannot say enough about change sizes.
Generally, smaller is better, hopefully within reason.  Do try to
keep things which will be confusing on their own together,
especially if changing one without the other will break something!</p></div>
<div class="ulist"><ul>
<li>
<p>
If a new feature is implemented and it is a larger one, try to
    identify if it can be split into smaller logical features; when
    in doubt, err on the smaller side.
</p>
</li>
<li>
<p>
Separate bug fixes from feature improvements.  The bug fix may
    be an easy candidate for approval and should not need to wait
    for new features to be approved.  Also, combining the two makes
    reviewing harder since then there is no clear line between the
    fix and the feature.
</p>
</li>
<li>
<p>
Separate supporting refactoring from feature changes.  If your
    new feature requires some refactoring, it helps to make the
    refactoring a separate change which your feature change
    depends on.  This way, reviewers can easily review the refactor
    change as a something that should not alter the current
    functionality, and feel more confident they can more easily
    spot errors this way.  Of course, it also makes it easier to
    test and locate later on if an unfortunate error does slip in.
    Lastly, by not having to see refactoring changes at the same
    time, it helps reviewers understand how your feature changes
    the current functionality.
</p>
</li>
<li>
<p>
Separate logical features into separate changes.  This
    is often the hardest part.  Here is an example:  when adding a
    new ability, make separate changes for the UI and the ssh
    commands if possible.
</p>
</li>
<li>
<p>
Do only what the commit message describes.  In other words, things which
    are not strictly related to the commit message shouldn&#8217;t be part of
    a change, even trivial things like externalizing a string somewhere
    or fixing a typo.  This help keep "git blame" more useful in the future
    and it also makes "git revert" more useful.
</p>
</li>
<li>
<p>
Use topic branches to link your separate changes together.
</p>
</li>
</ul></div>
</div>
</div>
<hr style="
  height: 2px;
  color: silver;
  margin-top: 1.2em;
  margin-bottom: 0.5em;
">
<div class="paragraph"><p>Part of <a href="index.html">Gerrit Code Review</a></p></div>
</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Version 2.5<br />
Last updated 2012-10-25 21:09:05 CEST
</div>
</div>
</body>
</html>
